(1) Field of the Invention
The invention relates to an image coding device that codes data relating to moving images, and more particularly, relates to an image coding device compliant with the H.264/AVC standard.
(2) Description of the Related Art
In recent years, with the development of digital imaging techniques, the amount of handled image data, particularly, the amount of moving image data is increasing. For example, in a High Definition (HD) image, which is in practical use these days, the amount of data is about six times as many as that of a conventional Standard Definition (SD) image.
On the other hand, with the improvement of information processing capability of computers and other equipment, moving images can be compressed using complex operations and the compression rate of image data is significantly increasing. H.264/AVC, which was standardized in recent years, is a standard that achieves about twice the compression rate of MPEG-2. H.264/AVC achieves a high compression rate by combining many compression techniques. Therefore, when compared to conventional compression methods, the amount of operations is also significantly increasing.
One compression technique used in H.264/AVC is entropy coding (variable-length coding). In H.264/AVC, two methods of entropy coding are available: Context-based Adaptive Variable Length Coding (CAVLC) and Context-based Adaptive Binary Arithmetic Coding) CABAC.
Coding in CABAC is categorized into mainly two processes. The first is a process called binarization, which converts multi-valued data to be coded into binary data. The second is a process to calculate and update the occurrence probability of binary data obtained by the binarization and perform arithmetic coding.
The binarization is performed on each syntax element, and an unconstant amount of bits are outputted at irregular intervals. On the other hand, since, in arithmetic coding, coding is performed based on the occurrence probability of binary data, which is sequentially updated for each bit, it is difficult to arithmetically code a large amount of bits per clock in terms of implementation. Therefore, a buffer to temporarily keep the binary data is needed between a binarization unit and an arithmetic coding unit.
FIG. 1 is a diagram showing an example of changes in throughputs or accumulated amounts in a binarization unit, a buffer and an arithmetic coding unit in a conventional image coding device.
In each graph of FIG. 1, a vertical axis represents the throughput or accumulated amount of each processing unit, one scale corresponding to one bit. Additionally, a horizontal axis represents time, one scale corresponding to one clock.
In addition, it is assumed that an arithmetic coding unit 53 in the drawing has a processing capability to process one bit/clock.
For example, binary data having two bits outputted from a binarization unit 51 at t0 is accumulated in a buffer 52 at t1. In addition, one of the two bits of binary data accumulated in the buffer 52 is arithmetically coded by the arithmetic coding unit 53 at t2.
As a result, at t2 , the accumulated amount in the buffer 52 should be one bit. When such data flow continues intermittently, a considerable increase in the accumulated amount in the buffer 52 is prevented.
However, for example, a case is assumed where, as shown in FIG. 1, binary data having five bits is outputted from the binarization unit 51 at t7 and t9. Even in this case, the amount processed by the arithmetic coding unit 53 is one bit/clock.
In other words, when a large amount of binary data is outputted almost continuously from the binarization unit 51, a processing delay with respect to the output from the binarization unit 51 occurs in the arithmetic coding unit 53, and the binary data is accumulated in the buffer 52. Therefore, CABAC needs a large-capacity buffer.
In addition, in H.264/AVC, the maximum amount of coding after arithmetic coding is specified; for example, the maximum amount of coding per macroblock is limited to 3200 bits where the format is 4-2-0 and bit_depth=8 bits. Further, as a result of arithmetic coding of a macroblock, when the amount of coding exceeds 3200 bits, coding must be performed again after the coding condition for the macroblock is changed. This also causes a processing delay in the arithmetic coding unit.
As described above, in an image coding device compliant with the H.264/AVC standard, processing capability per unit time of the arithmetic coding unit is constant. Therefore, when a large amount of binary data is generated at a given time, a processing delay involved in the arithmetic coding would have an effect on the flow of processing in the entire device.
Accordingly, a technique to reduce the effect of the processing delay involved in the arithmetic coding in the image coding device is disclosed (see e.g. Japanese Unexamined Patent Application Publication No. 2004-135251).
According to this conventional image coding device, the amount of binary data inputted into the arithmetic coding unit or the amount of data outputted from the arithmetic coding unit is monitored. In addition, when the amount of data exceeds a certain amount in a predetermined unit such as a picture, a slice or a macroblock, data to be arithmetically coded is not coded again, but I_PCM data, which is uncompressed data, is outputted as a bit stream (hereinafter also referred to as “stream”).
FIG. 2 is a functional block diagram showing the functional configuration of the conventional image coding device.
An image coding device 500 shown in FIG. 2 is an example of a conventional image coding device, which codes inputted image data and outputs the data as a bit stream. The overview of the operation of the image coding device 500 will be described below.
Note that image data includes various data related to a moving image, such as macroblock type control data or other attribute data, in addition to data related to the pixel value of a macroblock that constructs the moving image.
Image data to be coded is first inputted into a motion prediction unit 102 and an intra-picture prediction unit 103. In addition, the data is also inputted into an I_PCM data buffer 114, and stored as I_PCM data.
The motion prediction unit 102 detects a block highly correlated with a block to be coded from a picture different from a picture including the block to be coded. In addition, the motion prediction unit 102 determines a difference image between the block to be coded and the detected block, and outputs the difference image and a motion vector.
The intra-picture prediction unit 103 predicts the image of the block to be coded using the images of neighboring blocks. In addition, the intra-picture prediction unit 103 determines a difference image between the image of the block to be coded and the predicted image, and outputs the difference image and data representing the method of the prediction.
An input selection unit 104 selects either data outputted from the motion prediction unit 102 or the data outputted from the intra-picture prediction unit 103 based on each data amount, and inputs the data into an orthogonal transformation unit 105.
An orthogonal transformation coefficient obtained by orthogonal transformation performed by the orthogonal transformation unit 105 is inputted into a quantization unit 106, and quantized by the quantization unit 106.
A post-quantization coefficient, which is a quantized orthogonal transformation coefficient, is converted by a binarization unit 131 into binary data (shown as “bin” in the drawing), and inputted into an intermediate buffer 112. In addition, the I_PCM data is also outputted from the I_PCM data buffer 114 and inputted into the intermediate buffer 112.
After that, the binary data outputted from the intermediate buffer 112 is arithmetically coded by an arithmetic coding unit 132. At the time of the arithmetic coding, a variable table, in which variables representing the occurrence probability of “1” or “0” in the binary data are recorded, is referred to, and updated according to the result of the coding. The variable table is kept in the intermediate buffer 112, for example, and shown as “table A” in FIG. 2.
In addition, the data obtained by arithmetic coding (hereinafter referred to as “arithmetically coded data”) is kept in an output buffer 133.
Here, a data amount measuring unit 122 measures the amount of data inputted into the arithmetic coding unit 132. An I_PCM judging unit 121 judges whether the data to be outputted as a bit stream at each predetermined unit should be the arithmetically coded data kept in the output buffer 133, or the I_PCM data kept in the intermediate buffer 112, based on the amount of input data measured by the data amount measuring unit 122. More specifically, when the measured amount of input data exceeds a predetermined threshold, the I_PCM judging unit 121 judges that data to be outputted as a bit stream should be switched to the I_PCM data.
Note that although the amount of data inputted into the arithmetic coding unit 132 is used for the I_PCM judgment, the amount of data outputted from the arithmetic coding unit 132 may be used.
An output selection unit 113 follows the judgment of the I_PCM judging unit 121 to output either the arithmetically coded data kept in the output buffer 133 or the I_PCM data kept in the intermediate buffer 112.
In addition, when the I_PCM data is outputted, the above table A is updated at the time of obtaining the arithmetically coded data which is not to be outputted. Therefore, the table A has to be restored to its pre-update state.
Therefore, the table A in the pre-update state is kept in the intermediate buffer 112, for example. The table A in the pre-update state is shown as “table B” in FIG. 2. When the arithmetically coded data is not outputted, the arithmetic coding unit 132 rewrites the contents of the table A with the contents of the table B to restore the table A to the pre-update state.
Additionally, since the I_PCM data is outputted by bypassing the arithmetic coding unit, a large amount of data can be outputted per clock. Consequently, when a large amount of binary data is generated at the binarization unit 131, the output is switched to the I_PCM data as described above, so that the effect on the processing delay involved in arithmetic coding can be reduced.
However, in the above conventional technique, there are problems as described below.
(1) Everything that is generated flows into the intermediate buffer 112 together with binary data and I_PCM data. In other words, the binary data and the I_PCM data, which are practically not used for output streams, are also accumulated in the intermediate buffer 112.
Consequently, in the above conventional image coding device, it is necessary to provide a buffer which has a capacity larger than that of a buffer in which only binary data is temporarily accumulated as shown in FIG. 2.
(2) The arithmetically coded data outputted from the arithmetic coding unit 132 needs also to be kept in the output buffer 133 until whether to select the arithmetically coded data or the I_PCM data to be outputted is finally determined.
(3) When the I_PCM data is selected as an output stream, the updated variable table has to be restored to its pre-update state as described above. Therefore, in addition to the variable table, which is referred to and updated at the time of arithmetic coding, a variable table in the pre-update state always needs to be kept in the intermediate buffer 112 or the like.
Note that the capacity of each buffer can be reduced by accumulating the binary data, the I_PCM data, and two types of variable tables in their specific buffers, respectively. However, even in so doing, the necessary capacity of the buffer is the same for the whole image coding device.
As described above, although delay time involved in the re-coding of binary data is reduced when the above conventional technique is used, there is a problem that a large buffer capacity is still needed.
An aspect of the invention provides an image coding device that arithmetically codes binary data using a smaller buffer capacity.